This PR is an example to illustrate an approach in a discussion on the DDD-CQRS-ES Slack - my instinct is not to add this until we validate a scenario for which this truly is the best solution.

@dharmaturtle I'll likely take the cleanup aspects of this PR, and the FAQ from this and merge it after #272 for inclusion in the V3 RC

As noted previously, any concept that gets exposed in the public API has a cost in terms of adding stuff for readers of the code to traverse. That doesn't always make it a bad thing - sometimes naming or mentioning the concept can help people's thinking even if they opt not to actually use the facility in the end.

Please let me know if you've found a use case for needing to know the pre-version or have any other thoughts on this.

I've thrown pre-release binaries into source control before. I don't think it's a bad practice, and neither does Mark Seemann. There's no particular rush :)

Thats an interesting idea (though I think Mark's point is different - he'd still be installing the package from nuget, no?); in this instance it's more a concern of whether the feature should be added in the first instance than the release vehicle itself though.

If you wanted/needed to trial it, PR builds yield [alpha-badged] artifacts and can be released, though we try not to do that too often in order to avoid stressing nuget's performance.

On re-reading, I'm beginning to like the OP suggestion of exposing it as a breaking change in TransactAsyncEx - that provides the escape hatch just in case, without suggesting that it's part of any mainline API.